The CDPD Public Domain Collection for CDTV 4/CDPD_IV.bin/e/mailinglists/amigae.0294feb.archive/000030_donews!crash!kb…bt.co.uk!tonyp_Tue, 8 Feb 94 07:45:19 PST.msg

Internet Message Format | 1994-05-26 | 13KB

Received: by bkhouse.cts.com (V1.17-beta/Amiga)
      id <[e-mail]>; Tue, 8 Feb 94 07:45:19 PST
Received: from crash by donews.cts.com with uucp
    (Smail3.1.28.1 #18) id m0pTeLu-0001OoC; Mon, 7 Feb 94 14:22 PST
Received: from zaphod.axion.bt.co.uk by crash.cts.com with smtp
    (Smail3.1.28.1 #18) id m0pTSE6-0000awC; Mon, 7 Feb 94 01:25 PST
Received: from jasper.kbss.bt.co.uk (actually 132.146.9.31) by zaphod.axion.bt.co.uk with SMTP (PP);
          Mon, 7 Feb 1994 09:16:20 +0000
Received: from olivine.kbss.bt.co.uk by jasper.kbss.bt.co.uk; Mon, 7 Feb 94 09:14:56 GMT
Date: Mon, 7 Feb 94 09:14:54 GMT
Message-Id: <[e-mail]>
From: Tony Prichard 293834 <[e-mail]>
To: [e-mail]
Subject: <none>

SUBSCRIBE AmigaE
HELP AmigaE
FAQ AmigaE
From donews!crash!archiduc.irit.fr!vintenat Tue, 8 Feb 94 07:45:32 PST
Received: by bkhouse.cts.com (V1.17-beta/Amiga)
      id <[e-mail]>; Tue, 8 Feb 94 07:45:32 PST
Received: from crash by donews.cts.com with uucp
    (Smail3.1.28.1 #18) id m0pTeM1-0001UFC; Mon, 7 Feb 94 14:22 PST
Received: from archiduc.irit.fr by crash.cts.com with smtp
    (Smail3.1.28.1 #18) id m0pTSKe-00017iC; Mon, 7 Feb 94 01:32 PST
Received: from localhost (vintenat@localhost) by archiduc.irit.fr (8.6.4/8.6.4) id KAA12055; Mon, 7 Feb 1994 10:31:40 GMT
Date: Mon, 7 Feb 1994 10:31:40 GMT
Message-Id: <[e-mail]>
From: Lionel VINTENAT <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: I`m new here!

>   Not to mention DoMethod() in amiga.lib... I tried disassembling this but
>   I don`t know too much about how the C stubs work, so I got lost... :(
>   Anyway, any help in getting around these problems would be appreciated...

    Wouter gave me a doMethod() function for Amiga E which works very
well, I'll e-mail it to you tomorrow. Does anybody else want it ?

>2: I have had some joy with MUI, I got a basic window with some text up
>   and running, but nothing else... no DoMethod()! Gah!

    I wrote a macro preprocessor for Amiga E with MUI macros as example.
It's called Mac2E. E-mail me for more details.

>Finally, has anyone got any tips for reading tooltypes? My efforts crash the
>system, but I don`t have the source at hand :(

    I began a long time ago a program which needed tooltype reading. I gave
up this program (for the moment), but I can send to you the parts that you
are interested in. But the comments are in French !

    Lionel
From donews!crash!sheffield.ac.uk!D.Lamptey Tue, 8 Feb 94 07:45:41 PST
Received: by bkhouse.cts.com (V1.17-beta/Amiga)
      id <[e-mail]>; Tue, 8 Feb 94 07:45:41 PST
Received: from crash by donews.cts.com with uucp
    (Smail3.1.28.1 #18) id m0pTeM3-0001P9C; Mon, 7 Feb 94 14:22 PST
Received: from sun2.nsfnet-relay.ac.uk by crash.cts.com with smtp
    (Smail3.1.28.1 #18) id m0pTSUu-00013oC; Mon, 7 Feb 94 01:43 PST
Received: from ntsc.shef.ac.uk by pp.shef.ac.uk with SMTP (PP)
          id <[e-mail]>; Mon, 7 Feb 1994 09:38:09 +0000
Received: from mars.nattrans.COM by ntsc.shef.ac.uk (4.1/Derryck 1.1(mm))
          id AA10869; Mon, 7 Feb 94 09:39:51 GMT
Received: by mars.nattrans.COM (4.1/Derryck 1.2(sm)) id AA00601;
          Mon, 7 Feb 94 09:45:02 GMT
Via: uk.ac.sheffield; Mon, 7 Feb 1994 09:42:22 +0000
Date: Mon, 7 Feb 94 09:45:02 GMT
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: Re: STOP PRESS!!!


]
]Amiga E has a double page feature in Amiga Shopper this month, March
]issue, pages 62/63.
]
]Here are the contents of the "Checkout" box at the end of the article.
]
(Good News...)
]
]----8<----8<----8<----
]
]The reviewer is called Jason Hulance (are you on this mailing list,
]Jason? :-)
]

Yes, Jason is on this list, and contributes frequently.

Good to see you made it, Jason!
(Please e-mail me, wanna talk to you..)


Derryck.
_____________________________________________________________
Derryck Lamptey, MSc(Eng): National Transputer Support Centre
[e-mail]  Evening  voice:  (+44/0)742 309165
From donews!crash!mars.let.uva.nl!wouter Tue, 8 Feb 94 07:46:28 PST
Received: by bkhouse.cts.com (V1.17-beta/Amiga)
      id <[e-mail]>; Tue, 8 Feb 94 07:46:28 PST
Received: from crash by donews.cts.com with uucp
    (Smail3.1.28.1 #18) id m0pTeMQ-0002ScC; Mon, 7 Feb 94 14:23 PST
Received: from uranus.let.uva.nl by crash.cts.com with smtp
    (Smail3.1.28.1 #18) id m0pTWaj-0000LPC; Mon, 7 Feb 94 06:05 PST
Received: by uranus.let.uva.nl id AA01869
  (5.65c/IDA-1.4.4 for [e-mail]); Mon, 7 Feb 1994 15:00:04 +0100
Return-Path: <[e-mail]>
Date: Mon, 7 Feb 1994 15:00:04 +0100
Message-Id: <[e-mail]>
X-Organisation: Department of Computational Linguistics,
                University of Amsterdam
                Spuistraat 134, 1012 VB Amsterdam, The Netherlands
From: Wouter van Oortmerssen <[e-mail]>
To: [e-mail]
Subject: Types!


Hello All,

Here is yet another text I wrote with the purpose to help people
understand E better. It's a first version, so needs improvement. Enjoy!

---------------------------------------------------------------------------



                         UNDERSTANDING E TYPES

                       by Wouter van Oortmerssen



Intro
-----

Most problems people have while programming in E stem from their incorrect
view of how the E type-system works, and, admitted, this is not surprising
given the way it is described in the reference manual. Also, many people
have an idea how types work from their previous programming language, and
try to apply this to E, which is often fatal, because E is quite different
when it come to types.


The Type System
---------------

This may come as a shock to some readers, but E is in essense a TYPELESS
language. Indeed, variables may have a type, but this is only used as a
specification how to dereference a variable when it is used as a pointer.
In almost ALL other language constructions, variables are treated as all
being of the same type, namely the famous 32bit typeless value.

In practise this means that for example in expressions with the exception
of the ".", "[]" and "++" operators etc., all operators and functions work
on 32bit values, regardless of wether they represent booleans, integers,
reals or pointers to something.


So what are those Pointer Types?
--------------------------------

In the E type-system only 4 types exist, PTR TO CHAR, PTR TO INT,
PTR TO LONG and PTR TO <object>, where <object> is a name of a previously
defined OBJECT. When a variable (or an object member, as we'll see later)
is declared as being of this type, It means that if the variable contains
a value that is a legal pointer, this is how it should be dereferenced.


And what about LONG, ARRAY etc. ?
---------------------------------

All other types one may see in a DEF declaration a not really types, as
they really are only other ways of writing one of the above four. As an
example, ARRAY OF <type> is just another way of writing PTR TO <type>, with
the only difference that the former is automatically assigned the address
of an area of stackspace which is big enough to hold data for the #of
elements specified in square brackets.

Here's a table that shows all E 'types' in terms of the basic four:

ARRAY OF CHAR, ARRAY, STRING, LONG, <>   (are equal to)   PTR TO CHAR
ARRAY OF INT                             (is equal to)    PTR TO INT
ARRAY OF LONG, LIST                      (are equal to)   PTR TO LONG
ARRAY OF <object>, <object>              (are equal to)   PTR TO <object>

with "<>" I mean: no type specification at all.

- LONG is for variables that are not intended to be used as a pointer,
  i.e integers. It's equivalence with PTR TO CHAR is quite logical, as
  conceptually both talk about things that are measured in units of 1.
  (for example, "++" has the same effect on both)
- LIST and STRING are the same as their ARRAY equivalents, in respect
  to the fact that they're initialised to a piece of stack-space, but
  they're stack representation is a little more complex to facilitate
  runtime bounds-checking (when used with the correct functions).
- an <object> is equivalent to [1]:ARRAY OF <object>. both represent
  an initialised PTR TO <object>.

In an OBJECT one can have the same declarations, with the addition of CHAR
and INT (similar to LONG), and the ommission of LIST and STRING, as these
are complex objects in their own right, and cannot be part of an object.
(NOTE: in versions of E previous to v3.0, PTR TO and ARRAY OF types were
not available in OBJECTS)


Deferencing
-----------

Given a pointer p of some type,

"[]" may index other elements that are sequentially ordered next to
     the element it is currently pointing to. note that this allows for
     both positive and negative indices, and also no assumptions are made
     about where and howmany elements are actually allocated.

"++" sets the pointer to the next element in memory, "--" to the previous
     one. note that these operators always operate on the pointer and
     never on the the element the pointer is pointing to.

"."  works similar to "[]", only now indexes the pointer by name, i.e. the
     pointer must be a PTR TO <object>.

"[]" and "." may be concatenated to a pointer p in any sequence, given the
fact that the previous resulting value again is known to be of a "PTR TO"
type. (note that in versions of E previous to v3.0, this was restricted to
one "[]" and then one ".", notably because OBJECTs couldn't have PTRs in
them)

One does not need to write out a de-reference in total, as in other
languages, e.g. if p is an ARRAY OF obj, instead of having to write
p[index].member you can write just p[index], which logically results
in in the address of that object. This also explains why p[].member
is equivalent to p.member, since p[] is the same as p when it points
to an object.


Reference Semantics
-------------------

Another type-related issue that makes E somewhat different from other
languages and thus harder to grasp is it's accent on Reference Semantics
rather than Value Semantics. I'll try to argue why that's good here.

Informally, Reference Semantics means that objects in a language (mostly
other than the simple ones like LONGs) are represented by pointers, while
Value Semantics treats these objects as just being themselves. An example
of a language that has only Value Semantics is BASIC, examples of
languages that have them both are the C/C++ and Pascal type-of languages,
and examples of Reference only are newer Object Oriented languages like
Eiffel, functional languages like LISP and ofcourse E.

Using Reference Semantics doesn't mean being occupied with pointers
all the time, rather you're worrying about them a lot less then in the
mixed case or the Value-only case, especially since in real life programs
most non-trivial data-structures get allocated dynamically which implies
pointers. The best example of this is LISP, where one programs heavily
with pointers without noticing. In E, one could easily forget STRING
is a pointer, given the easy by which one can pass it around to other
functions; in C often lots of "&" are needed where in the equivalent E
case non are, and the Oberon equivalent of bla('hallo') looks like
bla(sys.ADR('hallo')) because the string doesn't represent a pointer,
but a value as a whole...

So why do languages have Value Semantics? beats me. One may thinks it's
conceptually nice but I can't imagine. A stronger argument seems to be
that accesses to objects that are no pointers can be better optimised by
a good compiler, but since only very trivial and static data-structures
can be build in this fashion, it's hardly an issue. Value semantics
is old-fashioned and will probably loose significance in new and upcoming
languages.

<note: this needs less hype>


Comparisons with C
------------------

long *x;                x:PTR TO LONG
long x[10];                --
long dummy[10], *x=&dummy;        x[10]:ARRAY OF LONG

<note: more here>

(-- = not possible, because of value-semantics)


Often Made Mistakes
-------------------

DEF s[50]:STRING
s:='bla'

This does not get the 'bla' into the string, however there's nothing
wrong with it either, just not what programmer means. The expression
on the righthandside of the ":=" results in a pointer, and replaces the
pointer that was already in s, namely one to an empty STRING. To actually
make a copy of 'bla' instead of just moving the pointer around (which
is desired in 90% of the cases), use StrCopy().

<note: more examples here>


Conclusions: So does Strong-Typing suck?
----------------------------------------

Yes and no.
<note: explanation here>